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Abstract 


This document describes a set of mappings which will enable inter 
working between systems operating the CCITT X.400 ( 1984 / 1988 ) 
Recommendations on Message Handling Systems, and systems running the 
Mail-11 (also known as DECnet mail) protocol. The specifications are 
valid within DECnet Phase IV addressing and routing scheme. 


The complete scenario of X.400 / RFC822 / Mail-11 is also considered, 
in order to cover the possible complex cases arising in multiple 
gateway translations. 


This document covers mainly the O/R address to DECnet from/to address 
mapping (and vice versa); other mappings are based on RFC 1327 and 
its eventual future updates. 


This is a combined effort of COSINE S2.2, the RARE MSG Working Group, 
and the IETF X.400 Ops Working Group. 


Chapter 1 - Introduction 
1.1. X.400 


The standard referred shortly into this document as "X.400" relates 
to the CCITT 1984 and 1988 X.400 Series Recommendations covering the 
Message Oriented Text Interchange Service (MOTIS). This document 
covers the Inter Personal Messaging System (IPMS) only. 


1.2. Mail-11 
Mail-11, also known as DECnet mail and often improperly referred as 


VMSmail, is the proprietary protocol implemented by Digital Equipment 
Corporation (DEC) to establish a real-time text messaging system 
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among systems implementing the DECnet Phase IV networking protocols. 
I3 s (REC822 


RFC822 was defined as a standard for personal messaging systems 
within the DARPA Internet and is now diffused on top of many 
different message transfer protocols, like SMTP, UUCP, BITNET, JNT 
Grey Book, CSnet. Its mapping with X.400 is fully described in 
RFC1327. In this document we will try to consider its relations with 
Mail-11, too. 


1.4. The user community 


The community using X.400 messaging system is currently growing in 
the whole world, but there is still a number of very large 
communities using Mail-11 based messaging systems willing to 
communicate easily with X.400 based Message Handling Systems. Among 
these large DECnet based networks we can include the High Energy 
Physics network (HEPnet) and the Space Physics Analysis Network 
(SPAN). 


These DECnet communities will in the future possibly migrate to 
DECnet Phase V (DECnet-OSI) protocols, converting thus their 
messaging systems to OSI specifications, i.e., merging into the X.400 
MHS; however the transition period could be long, and there could 
always be some DECnet Phase IV communities around. 


For these reasons a set of mapping rules covering conversion between 
Mail-11 and X.400 is described in this document. 


This document also covers the case of Mail-11 systems implementing 
the "foreign mail protocol" allowing Mail-11 to interface other mail 
systems, including RFC822 based system. 


Chapter 2 - Message Elements 
2.1. Service Elements 


Mail-11 protocol offers a very restricted set of elements composing a 
Inter Personal Message (IPM), whereas X.400 specifications support a 
complex and large amount of service elements. Considering the case 
where a message is relayed between two X.400 MHS via a DECnet network 
this could result in a nearly complete loss of information. To 
minimise this inconvenience most of X.400 service elements will be 
mapped into Mail-11 text body parts. To consider also the case when a 
message originates from a network implementing RFC822 protocols and 
is relayed via Mail-11 to and X.400 MHS, the applied mapping from 
X.400 service elements into Mail-11 text body part the rules 
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specified in RFC1327 and their updates will be used, producing an 
RFC822-like header. 

2.2. Mail-11 service elements 
All envelope (P1) and header (P2) Mail-11 service elements are 
supported in the conversion to X.400. Note that Mail-11 P1 is solely 
composed by P1.From and P1.To, and any other Mail-11 element belongs 
to Mail-11 P2: 

- PI Erom 

maps to P1.Originator 

maps to P1.Primary Recipient 
- P2.From 

maps to P2.Originator 


maps to P2.Primary Recipient 


maps to P2.Copy Recipient 


- Date 
maps to Submission Time Stamp 


- Subj 
maps to Subject 


Any eventual RFC822-like text header in Mail-11 body part will be 
interpreted as specified into RFC1327 and its updates. 


2.3. X.400 service elements 


The following X.400 service elements are supported directly into 
Mail-11 conversion: 


- Pl.Originator 
maps to Pl.’From’ 


- P1l.Primary Recipients 
maps to Pl1.’To’ 


- P2.Originator 
maps to P2.’From’ 
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- P2.Primary Recipients 
maps to P2.’To’ 


- Copy Recipients 
maps to ’Cc’ 


- Submission Time Stamp 
maps to ’date’ 


- Subject 
maps to ’Subj’ 


The following X.400 service element is partially supported into 
Mail-11 conversion: 


- Blind Copy Recipient 
to ensure the required privacy, when a message contains 
a BCC address, the following actions occurs: 

- a new message is created, containing the body parts; 
- a new envelope is added to the new message, containing 
the originator and the BCC recipient addresses only; 

- a note is added to the message informing the BCC 
recipient about the fact that the message was a BCC; 

- the new message is delivered separately; 

- a note is added to the message delivered to TO and CC 
recipients informing them about the fact that there 
were some BCC recipients, too. 


Any other X.400 service element support is done accordingly to 
RFC1327 including the mapped element into the RFC822-like header into 
Mail-11 body part. 

Chapter 3 - Basic Mappings 


The basic mappings indicated in RFC1327 and its updates should be 
fully used. 


Chapter 4 - Addressing 

4.1. Mail-11 addressing 
Mail-11 addressing can vary from a very simple case up to complex 
ones, if there are other Mail-11 to "something-else" gateways 


involved. In any case a Mail-11 address is an ASCII string composed 
of different elements. 
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4.2. X.400 addressing 
On the other hand, An X.400 O/R address is a collection of 
attributes, which can anyway be presented as an IA5 textual 
representation as defined in chapter 4 of RFC1327. 


4.3. Mail-11 address components 


Let us start defining the different parts composing a Mail-11 
address. We can consider any Mail-11 address as composed by 3 parts: 


[[route]::] [[node]::] local-part 


where ’route’ and node’ are optional and only ’local-part’ is 
compulsory. 


Here comes a strict definition of these elements 


node = *(ALPHA/DIGIT) / *DIGIT / *DIGIT "." *DIGIT 
route = *(node "::") 

local-part = username / nickname / for-protocol 
username = * (ALPHA/DIGIT) 

nickname = <printablestring - <" " and HTAB>> 
for-protocol = (f-pref f-sep <">f-address<">) 


f-pref = * (ALPHA/DIGIT) 

f-sep = wom / Maan 

f-address = printablestring / RFC822-address / X400-text-address 
X400-text-address = <textual representation of an X.400 O/R addr> 


Please note that in x-text-address both the ";" notation and the "/" 
notation are equivalent and allowed (see examples in different sect.) 
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Some examples: 


route node local-part 
USER47 
MYNODE: :BETTY 
BOSTON: :CLUSO2: :GOOFY1: :MARY34 
INS"M.P.Tracy@Dicdum.cc.edu" 
UCLA13: :MVAX93: :MRGATE: : "MBOX1: :MBX34: :MYC3::BOB" 
MIAMI2::George.Rosenthal 
CCUBVX: :VS3100: :Jnet$"IAB3425@IBAX23L" 
MRGATE: :"C=xx: :A=bbb: :P=ppp: :S=Joe" 
MAINVX: : INS"path1!path2!user%dom" 
GWX400: :gw%"C=xx; ADMD=aaa; PRMD=ppp; S=Lee; " 
GX409A: :x400%"/C=xx/A=aaa/P=ppp/S=Lee" 
smtp%"postmast@nodeb.bitnet" 
MICKEY: :PRFGAT: :profs¢"NANCY@IBMB" 
edu%S"HU427BDSCSUNIB@abc.acme.edu" 


Chapter 5 - Mapping 
5.1. Mapping scheme 


DECnet address field is somehow a ’flat land’ with some obliged 
routes to reach some hidden areas. Thus a truly hierarchical mapping 
scheme using mapping tables as suitable for RFC822 is not the 
appropriate solution. A fixed set of rules using DDAs support is 
defined in order to define the mapping. 


Another important aspect of the problem is the coexistence of many 
disjoint DECnet networks, using the same DECnet address space, i.e., 
common X.400 and/or RFC822 mailing system acting as glue to connect 
different isolated Mail-11 islands. Thus, to identify uniquely each 
DECnet network we must also introduce the concept of ’DECnet network 
name’, which we will refer shortly as /’/net’ from now onwards. We 
define as ‘net’ a unique ASCII string identifying the DECnet network 
we are connected to. To be more specific, the ’net’ element will 
identify the DECnet community being served, i.e., it could also 
differ from the actual official network name. Aliases are allowed for 


the 
net = ’HEPnet’ the High Energy Physics DECnet network 
net = ' SPAN’ the Space Physics Analysis Network 
net = ‘Enet’ the Digital Equipment Corporate Network 


The need of labelling each DECnet network with its name comes also 
from the requirement to implement the ’intelligent’ gateway, i.e., 
the gateway which is able to understand its ability to connect 
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directly to the specified DECnet network, even if the O/R address 
specify a path to a different gateway. A more detailed discussion of 
the problem is in 5.3 and 5.5. 


A registry of ’net’ attributes and their correspondent gateways must 
also be implemented to insure uniqueness of names. A simple table 
coupling /net’ and the gateway address is used, in a syntax similar 
to the ’gate’ table used in RFC1327. An example: 


HEPnet #OUSCosine-gw.O$@.PRMDSinfn.ADMDSgarr.CSIT# 
SPAN#OUSCosine-gw.0O$@.PRMDSinfn.ADMDSgarr.CSIT# 
SPAN#OSESRIN1.PRMDSesa.ADMD$Master400.CSit# 
Ambiguous left entries are allowed. Gateway implementations could 
simply choose among one of them, or try them all in cyclic order to 
obtain better performances. 
In order to keep the mapping rules very simple, avoiding the need to 
analyse Mail-11 addresses to distinguish the ‘route’, ’node’ and 
needed to cover the mapping problem. 


5.2. Mail-11 --> X.400 


We define the following Domain Defined Attributes to map a Mail-11 
address: 


DD.Dnet 
DD.Mail-11 


We thus define the mapping rule 
route: :node::localpart 
maps into 


C=xx; ADMD=yyy; PRMD=zzz; O=000; OU=uuu; DD.Dnet=net; 
DD.Mail—-11=route: :node::localpart; 


with 
xx = country code of the gateway performing the conversion 
yyy = Admd of the gateway performing the conversion 
zzz = Prmd of the gateway performing the conversion 


ooo = Organisation of the gateway performing the conversion 
uuu = Org. Unit(s) of the gateway performing the conversion 
net = name of the DECnet network (e.g., HEPnet, SPAN,...) 


(’z2zz',’ooo’,’uuu’ being used or dropped appropriately in order to 
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identify uniquely within the X.400 MHS the gateway performing the 
conversion). 

The following defaults also apply: 


if ’node’ is missing and we are mapping the Mail-11 originator (From) 
then ‘node’ defaults to the DECnet node name of the gateway (gwnode) ; 


if ’node’ is missing and we are mapping the Mail-11 recipient (To, 
Cc) then ’node’ defaults to the DECnet node name of the ’From’ 
address. 


if ’DD.Dnet=net’ is missing, then it defaults to a value defined 
locally by the gateway: if the gateway is connected to one DECnet 
network only, then ‘net’ will be the name of this unique network; if 
the gateway is connected to more than one DECnet network, then the 
gateway will establish a ’first choice’ DECnet network, and ‘net’ 
will default to this value. 


In case ’local-part’ contains ’x400-text-address’ see also section 
64.537 


In case ’local-part’ contains ’RFC822-address’ see also section 
6.4.4. 


5.2.1. Examples 
Let us suppose that: 


the DECnet network name (net) is ‘HEP’; 

the DECnet node name of the gateway (gwnode) is ’X4TDEC’; 

the Country Code of the gateway is ’IT’ and its ADMD is ‘’garr’ 
(and these two fields are enough to identify uniquely the gateway 
within the X.400 MHS). 


USER47 
C=it; ADMD=garr; DD.Dnet=HEP; DD.Mail-11=X4TDEC: :USER47; 


MYNODE: : BETTY 
C=it; ADMD=garr; DD.Dnet=HEP; DD.Mail-11=MYNODE::BETTY; 


BOSTON: :CLUSO2: :GOOFY1: :MARY34 
C=it; ADMD=garr; DD.Dnet=HEP; DD.Mail-11=BOSTON: :GOOFY1: :MARY34; 


UCLA13: :MVAX93: :MRGATE: :"MBOX1: :MBX34:MYC3::BOB" 
C=it; ADMD=garr; DD.Dnet=HEP; 
DD.Mail-—11=UCLA13: :MVAX93::MRGATE:: (q)MBOX1: :MBX34: :MYC3: : BOB (q) 
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MIAMT2: :George.Rosenthal 
C=it; ADMD=garr; DD.Dnet=HEP; DD.Mail-11=MIAMI2::George.Rosenthal; 
MRGATE: :"C=xx: :A=bbb: :P=ppp: :S=Joe" 
C=it; ADMD=garr; DD.Dnet=HEP; 
DD .Mail—-11=X4TDEC: :MRGATE:: (q) C=xx: :A=bbb: :P=ppp: :S=Joe (q) 
MAINVX: :InS"path1!path2!user%dom" 
C=it; ADMD=garr; DD.Dnet=HEP; 
DD.Mail—-11=MAINVX::In(p) (q) pathl1 (b) path2 (b) user (p) dom (q) 
5.3. X.400 encoding of Mail-11 --> Mail-11 


In order to assure path reversibility in case of multiple Mail- 
11/X.400 gateway crossing we must distinguish two cases: 


- DD.Dnet=net is known to the gateway as one of the DECnet networks 
it is connected to. In this case the mapping is trivial: 


C=xx; ADMD=yyy; PRMD=zzz; O=000; OU=uuu; DD.Dnet=net; 
DD.Mail-11=route: :node::localpart; 


(see sect. 5.2 for explication of '’xx’,’yyy’,’zzz’,'’oo0o’,’uuu’,’net’) 
maps into 
route: :node::localpart 
- DD.Dnet=net is NOT known to the gateway as one of the DECnet 
networks it is connected to. In this case the mapping rule 


described into section 5.4 apply: 


C=xx; ADMD=yyy; PRMD=www; DD.Dnet=net; 
DD.Mail-—11=route: :node::localpart; 


maps into 


gwnode: :gwe"C=xx; ADMD=yyy; PRMD=www; DD.Dnet=net; 
DD.Mail-11=route: :node::localpart;" 


5.3.1. Examples 
Let us suppose that: 
the DECnet network name (net) is ‘HEP’; 
the DECnet node name of the gateway (gwnode) is ’X4TDEC’; 


the Country Code of the gateway is ’IT’ and its ADMD is ’garr’; 
(and these two fields are enough to identify uniquely the gateway 
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within the X.400 MHS). 


C=it; ADMD=garr; DD.Dnet=HEP; 
DD.Mail-11=X4TDEC: :MRGATE:: (q) C=ab: :A=dsa: :P=qwty: :OU=mie: :S=Cly (q) 
MRGATE: :"C=ab: :A=dsa: :P=qwty: :OU=mie::S=Cly" 


C=it; ADMD=garr; DD.Dnet=EASYNET; DD.Mail-—11=ROM01::CARLO; 
X4TDEC: :gwS"C=it; ADMD=garr;DD.Dnet=EASYNET; 
DD.Mail-11=ROM01::CARLO;" 


(in the above example ’/EASYNET’ is supposed to be not connected to 
our gateway located on X4TDEC DECnet node). 


5.4. X.400 --> Mail-11 
The mapping of an X.400 O/R address into Mail-11 is done encoding the 
various attributes into the X400-text-address as defined in chapter 4 
of RFC1327, and including this as ’f-address’. A ’f-pref’ and a the 
DECnet node name of the gateway. 
Thus 
x400-text-address 
will be encoded like 
gwnode: :gws"x400-text-address" 
having spaces dividing attributes as optional. 
5.4.1. Example 
Let us suppose that: 
the DECnet node name of the gateway (gwnode) is ’X4TDEC’; 
Thus 
C=gb; ADMD=Gold 400; PRMD=AC.UK; O=ucl; OU=cs; G=Jim; S=Clay; 
will be encoded like 
X4TDEC: :gw%"/C=gb/A=Gold 400/P=AC.UK/O=ucl/OU=cs/G=Jim/S=Clay" 
or its equivalent with the ";" notation 


X4TDEC: :gws"C=gb; ADMD=Gold 400; PRMD=AC.UK; O=ucl; OU=cs; G=Jim; S=Clay;" 
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5.5. Mail-11 encoding of X.400 --> X.400 

It can happened that Mail-11 is used to relay messages between X.400 

systems; this will mean multiple X.400/Mail-11 gateway crossing and 

we will encounter Mail-11 addresses containing embedded X.400 

informations. In order to assure path reversibility we must then 

distinguish two cases: 

- the embedded X.400 address belongs to a domain whose naming and 
routing rules are known to the global X.400 MHS. In this case the 
mapping is trivial: 

route: :gwnode: :gws"x400-text-—address" 
maps into 
x400-text-address 


‘route’ and ’gwnode’ are mapped into X.400 Trace service elements. 


- the encoded X.400 domain does not belong to the global X.400 name 
space. In this case the mapping rule described into section 5.2 


apply: 
route: :gwnode: :gws"x400-text-—address" 
maps into 


C=xx; ADMD=yyy; DD.Dnet=net; 
DD.Mail-—11=route: :gwnode::gw(p) (q) x400-text-—address (q); 


The latter case is deprecated and must be regarded as a possible 
temporary solution only, while waiting to include into the global 
X.400 MHS also this domain. 

5.5.1. Examples 


Let us suppose that: 


the DECnet network name (net) is ’HEP’; 

the DECnet node name of the gateway (gwnode) is ’X4TDEC’; 

the Country Code of the gateway is ’IT’ and its ADMD is '’garr’; 
(and these two fields are enough to identify uniquely the gateway 
within the X.400 MHS). 


X4TDEC: :gwS"C=fr; ADMD=atlas; PRMD=ifip; O=poly; S=Moreau;" 
C=fr; ADMD=atlas; PRMD=ifip; O=poly; S=Moreau; 
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X4TDEC: :gw"C=zz;ADMD= ;PRMD=Botwa; O=Miner; S=Chiuaw;" 
C=it; ADMD=garr; DD.Dnet=HEP; 
DD.Mail-11=X4TDEC::gw(p) (q) C=zz;ADMD= ; 
PRMD=Botwa; O=Miner; S=Chiuaw; (q) 


(in the above example C=zz is unknown to the global X.400 MHS) 
Chapter 6 - Complex mapping 
6.1. The protocol triangle 

The bilateral mappings described in chapter 5 must be extended in 


order to cover also the case in which also RFC822 addressing is 
involved, and the following triangular situation occurs: 


x.400 
i N 
/ \ 
/ \ 
Mail-11----RFC822 


The X.400 - RFC822 side is fully covered by RFC1327, and the previous 
chapters in this document cover the Mail-11 - X.400 side. 


Currently a number of implementations also perform the mapping along 
the Mail-11 - RFC822 side. The most important among these de facto 
standards are discussed in Appendix A, jointly with a Mail-11 - 
RFC822 mapping scheme which covers this side of the triangle. 
6.2. RFC822 mapped in Mail-11 

The ’RFC822-address’ is usually included in ’local-part’ as 

route: :gwnode: :gw%s"rfc822-address" 
an example 

NVXA23::SMTPGW: :ins"M.T.Rose@CS.UCLA.edu" 


6.3. Mail-11 mapped in RFC822 


There are different styles in mapping a Mail-11 address in RFC822; 
let’s have a short summary. 


-— Mail-11 address encoded in "Left Hand Side" (LHS) of RFC822 
address, using "%" syntax or "::" syntax; 


route: :node::localpart 
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maps to 
localpart %node%route@gw-domains 
or 
"route: :node::localpart"@gw-domains 
where 'gw-domains’ identify uniquely the Mail-11 / RFC822 gateway. 


—- Mail-11 address maps partly to LHS and partly to ’domain’ part of 
RFC822 address: 


node::localpart 
maps to 
localpart@node.gw-domains 
- Mail-11 address is completely hidden by a mapping table / directory 
and the resultant RFC822 address contains no trace at all of the 


original address. 


As you could notice, in any of the quoted cases the resultant RFC822 
address is not distinguishable from a genuine RFC822 address. 


6.4. Multiple conversions 
Let us now examine briefly the possible situations which involve 
multiple conversions, having one protocol as a relay between the 
other two. This summary suggest some possible enhanced solutions to 
avoid heavy and unduly mappings, but the ’step by step’ approach, 
considering blindly one conversion as disjointed to the other, as 
described in the previous sections, can always be used. 

6.4.1. X.400 --> RFC822 --> Mail-11 
We apply the RFC1327 rules to the first step, obtaining an RFC822 
address which can be mapped in Mail-11 using the ’f-address’ field, 
as described in section 6.2. 
an example: 

C=gb; ADMD=Gold 400; PRMD=AC.UK; O=UCL; OU=cs; G=Jim; S=Clay; 

maps accordingly to RFC1327 to 


Jim.Clay@cs.UCL.AC.UK 
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and finally becomes 
SMTPGW: :InS"Jim.Clay@cs.UCL.AC.UK" 


where ’SMTPGW’ is the DECnet node name of the machine running the 
RFC822 to Mail-11 gateway. 


6.4.2. Mail-11 --> RFC822 --> X.400 
Some of the possible mapping described in section 6.3 apply to the 
Mail-11 address, hiding completely its origin. The RFC1327 apply on 
the last step. 
an example: 
RELAY: :MYNODE: : BETTY 
could map into RFC822 as 
BETTYSMYNODE@RELAY.dnet.gwl.it 
and accordingly to RFC1327 
C=it; A=garr; P=doml; O=gwl; OU=RELAY; S=BETTY (p)MYNODE; 


where /’dnet.gwl.it’ is the domain of the machine running the Mail-11 
to RFC822 gateway. 


6.4.3. X.400 --> Mail-11 --> RFC822 
The X.400 address is stored into Mail-11 ’f-address’ element as 
described in sections 5.3 and 5.4; then if the Mail-11 to RFC822 
gateway is able to understand the presence of a '’x400-text-address’ 
into the Mail-11 address, then it applies RFC1327 to it, and encodes 
header. Otherwise it applies the rules described in 6.3 
an example: 

C=gb; ADMD=Gold 400; PRMD=AC.UK; O=UCL; OU=cs; G=Jim; S=Clay; 

will be encoded like 


XA4TDEC: :gw%"/C=gb/A=Gold 400/P=AC.UK/O=UCL/0U=cs/G=Jim/S=Clay" 


If the Mail-11 to RFC822 gateway recognise the x400-text-address, 
then the address becomes, accordingly to RFC1327 


Jim.Clay@cs.UCL.AC.UK 
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and the following RFC822 header line is added 

Received: from X4TDEC with DECnet (Mail-11) on xx-xxx-xxxx. 
Otherwise one of the dumb rules could produce 

gw%"/C=gb/A=Gold 400/P=AC.UK/O=UCL/OU=cs/G=Jim/S=Clay"@X4TDEC.doms 

6.4.4. RFC822 --> Mail-11 --> X.400 

The RFC822 address is encoded in Mail-11 f-address element as 
described in sect. 6.2; then if the Mail-11 to X.400 gateway is able 
to understand the presence of an ’RFC822-address’ into the Mail-11 


address, then it applies RFC1327 to it, and encodes ’route’ and 
applies the rules described in 5.2 and 5.5. 


an example: 
Jim.Clay@cs.UCL.AC.UK 
will be encoded like 
SMTPGW: :InS"Jim.Clay@cs.UCL.AC.UK" 


If the Mail-11 to X.400 gateway recognise the RFC822-address, then 
the address becomes, accordingly to RFC1327 


C=gb; ADMD=Gold 400; PRMD=AC.UK; O=UCL; OU=cs; G=Jim; S=Clay; 


and a ’trace’ record is added into the X.400 P1 data, stating that a 
node named SMTPGW was crossed. 


Otherwise dumb rule produces 


C=it; ADMD=garr; DD.Dnet=HEP; 
DD.Mail-11=SMTPGW::In(p) (q) Jim.Clay (a) cs.UCL.AC.UK (q) 


6.4.5. RFC822 --> X.400 --> Mail-11 
We apply RFC1327 to the first conversion, obtaining an X.400 address. 
Then the rules described in sections 5.3 and 5.4 are used to store 
the X.400 address as ’x400-text-address’ into the Mail-11 
an example: 


Jim.Clay@cs.UCL.AC.UK 


maps accordingly to RFC1327 to 
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C=gb; ADMD=Gold 400; PRMD=AC.UK; O=UCL; OU=cs; G=Jim; S=Clay; 
and finally becomes 
SMTPGW: :gw%"/C=gb/A=Gold 400/P=AC.UK/O=UCL/0OU=cs/G=Jim/S=Clay" 


where ’SMTPGW’ is the DECnet node name of the machine running the 
X.400 to Mail-11 gateway. 


6.4.6. Mail-11 --> X.400 --> RFC822 


The Mail-11 address is encoded as specified in sections 5.2 and 5.5; 
then RFC1327 is used to convert the address in RFC822. 


an example: 
RELAY: :MYNODE: : BETTY 
maps into X.400 as 
C=it; ADMD=garr; DD.Dnet=HEP; DD.Mail-11=RELAY: :MYNODE::BETTY; 
and accordingly to RFC1327 
"/C=it/A=garr/DD.Dnet=HEP/DD.Mail-11=RELAY: :MYNODE: :BETTY"@gw2.it 


where /’gw2.it’ is the domain of the machine running the RFC1327 
gateway. 


Appendix A Mail-11 - RFC822 mapping 
A.1 Introduction 


The implementation of a Mail-11 - RFC822 gateway was faced by many 
software developers independently, and was included in many mail 
products which were running on both VAX/VMS and UNIX systems. As 
there was not a unique standard mapping way, the implementations 
resulted into a number of possible variant methods to map a Mail-11 
address into an RFC822 one. Some of these products became then 
largely widespread, starting to create a number of de facto mapping 
methods. 


In this small appendix some sort of standardisation of the mapping 
problem is considered, trying to be compatible with the existing 
installed software. We must also remind that, in some cases, only 
simple Mail-11 addresses could be mapped into RFC822, having complex 
ones producing all sort of quite strange results. 
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On the other hand, the mapping of an RFC822 address in Mail-11 was 
quite straightforward, resulting in a common definition which uses 
"Mail-11 foreign mail protocol" to design an RFC822 address: 


[[node::] [node::]...]prot%"rfc-822-address" 
or 
[node::] [node::]...]::"rfc-822-address" 


A.2 De facto implementations 


A considerable number of de-facto implementations of Mail-11/RFC822 
gateways is existing. As said in the introduction, the mapping of 
RFC822 addresses in Mail-11 is accomplished using the foreign mail 
protocol syntax and is thus unique. 


On the other hand, Mail-11 addresses are encoded in RFC822 syntax in 
various ways. Here are the most common ones: 


"node: :user"@gateway-—address 
userSnode@gateway-address 
user@node.decnet.domains 
user%Snode.dnet@gateway-address 


aap 


Let’s have a quick look to these different choices. 


a - This form simply encloses as quoted Left Hand Side string the 
original Mail-11 address into the RFC822 address of the 
Mail-11/RFC822 gateway. This method is fully conformant with 
RFC822 syntax, and the Mail-11 address is left untouched; thus 
no encoding rules need to applied to it. 


b - As one will immediately notice, this form has nothing in it 
indicating the address is a Mail-11 one; this makes the encoding 
indistinguishable from a similar encoding of RSCS (BITnet) 
addresses used by some IBM VM Mailer systems. It should thus be 
deprecated. 


c - In this case a sort of 'reserved word’ (decnet) embedded into 
the address itself identifies the presence of a Mail-11 original 
address preceding it. The decoding is possible, dropping 
‘domains’ and extracting ’user’ and ’node’ parts. However complex 
Mail-11 addresses cannot be mapped properly in this syntax, and 
there is no specific rule for adding the ’domains’ part of the 
address. 
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d- In this case again there is a ’reserved word’ (dnet) which make 
possible the identification of the original Mail-11 address; 
'gateway-address’ points to the Mail-11/RFC822 gateway and ’node’ 
and ’user’ information can be easily drawn from the address. 
However complex Mail-11 addresses cannot be embedded easily into 
this syntax. 


A.3 Recommended mappings 
From the examples seen in the previous paragraphs we can derive a 
canonical form for representing the mapping between Mail-11 and 
RFC822. 

A3.1 RFC822 mapped in Mail-11 


The mapping of an RFC822 address in Mail-11 is straightforward, using 
the "Mail-11 foreign mail protocol" syntax. The two possible variants 


are: 

[[node::] [node::]...]prot%s"rfc-822-address" 
or 

[node::] [node::]...]::"rfc-822-address" 


A3.2 Mail-11 mapped in RFC822 


RFC822 foresee a canonical form for representing non-RFC822 
addresses: put the foreign address in local part (Left Hand Side, 
LHS) is a form as similar as possible to its original syntax. Thus 
the suggested mapping is: 


"Mail-1l-address"@gateway-address 
This format assures also the return path via the appropriate gateway. 
A.4 Conclusions 


A standard way of mapping Mail-11 addresses into RFC822 and vice 
versa is feasible. A suggestion is thus made to unify all existing 
and future implementations. It should be noted, however, that there 
is no way to specify in these mappings the name of the decnet 
community owning the encoded address, as it was done for X.400, thus 
the implementation of the ’intelligent’ gateway in this case is 
impossible. 
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